home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / c_client.arc / text0082.txt < prev    next >
Encoding:
Text File  |  1993-07-31  |  1.8 KB  |  45 lines
  1. Actually I don't think preserving flags on a COPY is always the right 
  2. thing to do. For example is someone saves a messages with the \DELETE 
  3. flag on, the flag should probably not be copied. The user probably is 
  4. saving the message from the next expunge. 
  5.  
  6. The best solution would, I believe, enable you to set the flags as you wish
  7. on all the operations without having to actually open the mailbox. That
  8. is, the behavior should be left up to the user interface, and not imposed 
  9. by IMAP.
  10.  
  11. LL
  12.  
  13.  
  14. On 12 Jul 1993, Adam Treister wrote:
  15.  
  16. > Just to chime in quickly, I think the status of flags needs to be preserved
  17. > across transfer of messages.  I can see that its messy to implement, but
  18. > its "the right thing" as far as the user is concerned. If the user has set
  19. > keywords, they need to be preserved. 
  20. > 
  21. > I could take it so far as to say that a client may want to be able to add
  22. > status information to the header in the process of doing the move.  Imagine
  23. > an agent which moves mail from the inbox to a folder without the user
  24. > actually knowing.  It may be beneficial if the agent adds a X-Moved-Because
  25. > header in the process to include the rule that caused the action.  (This
  26. > may be a bit futuristic, but was the first example that came to mind.  I'm
  27. > sure there are more mundane examples.)
  28. > 
  29. > It sure seems to me that there is a lot of redundancy between Move, Copy,
  30. > and Append, and maybe preservation of attributes could be a differentation
  31. > among these commands. (The implication is that Copy is creating a new
  32. > message, which may not have attributes set, but Move should not change the
  33. > message in the process)
  34. > 
  35. > Adam
  36. > --------------------------------------------------
  37. > Adam Treister  <treister@forsythe.stanford.edu>
  38. > Polya Hall 205, Stanford CA 94305 - (415) 725-9449
  39. > --------------------------------------------------
  40. > 
  41. > 
  42. > 
  43.  
  44.  
  45.